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Introduction~The  Symbol  Table  Task 

Previous  reports  [Shaw76b,  Wulf76a,b]  have  described  the  Alphard  programming 
language  and  its  associated  verification  methodoiogy.  These  reports  developed  Alphard 
definitions  for  the  canonical  examples  of  data  abstractions  (stacks,  queues,  and  sets).  These 
examples  are  sufficiently  simple  to  be  grasped  readily,  and  they  have  appeared  often  enough 
in  other  ianguages  that  the  reader  may  compare  various  approaches  to  their  definition.  There 
is,  however,  a danger  in  considering  only  these  examples.  It  is  possible  that  an  approach  will 
work  for  only  the  easy  examples,  or  that  the  definition  of  something  more  complex  will  be  far 
less  elegant. 

Therefore,  in  this  report  we  shall  consider  a larger,  more  realistic  example:  an 
abstraction  of  a symbol  table.  For  comparison  purposes  the  reader  may  wish  to  refer  to  the  I 

similar  example  given  in  [Guttag76]  and  to  a hashtabie  example  in  [Wegbreit76]. 

Suppose  that  we  must  produce  a number  of  compilers,  assemblers,  and  interpreters  to  I 

operate  on  several  different  computers.  Each  such  system  wiii  contain  a symbol  table  | 

mechanism;  although  each  system  will  have  its  own  requirements,  many  of  the  gross,  abstract  ] 

properties  of  these  symboi  tabies  will  be  the  same.  It  seems  desirable  to  have  a single  | 

implementation  of  these  common  aspects  which  is  verified;  that  will  be  our  aim.  I 

But  what  are  the  common  properties?  Many  texts  [e.g.,  Gries71]  describe  a symbol  j 

table  as  a mapping  from  identifiers  (strings  appearing  in  a source  program)  to  a set  of  | 

attributes  associated  with  those  identifiers.  Examples  of  such  attributes  include  "type",  "run-  | 

time  memory  address",  "number  of  dimensions"  (for  arrays),  etc.  In  some  cases,  the  mapping  | 

may  be  sensitive  to  the  context  in  which  the  identifier  occurs.  (Algol-like  block  structure  is  | 

the  most  common  example  of  this  context  sensitivity;  the  mapping  from  identifier  to  attributes  \ 

depends  upon  the  block  in  which  the  identifier  appears.  Name  qualification,  as  in  field  j 

selection  from  a record,  is  another  example  in  which  the  interpretation  of  the  field  selector 
depends  upon  the  type  of  the  record.)  The  common  properties,  then,  are  ones  which  involve  ] 

the  application  and  manipulation  of  this  mapping;  principally  | 

- some  means  to  apply  the  mapping,  i.e.,  to  find  the  attributes  associated  with  the  ' 

occurrence  of  an  identifier. 

- some  means  to  alter  the  mapping,  e.g.,  by  inserting  and/or  deleting  entries  and  ; 

signaling  changes  in  context.  I 


Since  we  want  our  abstraction  to  serve  a spectrum  of  languages,  system  types  (e.g., 
compilers  and  assemblers),  and  machines,  it  would  not  be  appropriate  to  include  the  specific 
attributes  as  part  of  the  abstraction.  Rather,  we  shall  presume  that  the  user  of  our 
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abstraction  wilt  define  some  mechanism  for  storing  and  retrieving  attributes,  e.g.,  a vector  of 
records;  our  abstraction  wilt  then  provide  a mapping  from  an  identifier  to  a unique  integer 
which,  for  example,  may  then  be  used  as  an  Index  into  this  vector  of  attribute  records. 

Concerning  the  issue  of  context  sensitivity,  we  shall  provide  an  abstraction  which 
supports  block  structure  because  (1)  it  is  the  more  general  case  and  (2)  with  proper 
implementation,  the  generality  costs  very  little  when  it  is  not  used.  We  shall  not  explicitly 
provide  for  the  kind  of  context  sensitivity  needed  for  record  selectors,  but  we  shall  show  how 
the  abstraction  may  be  used  to  achieve  it. 

Note  that  the  informal  term  "block-structured"  does  not  describe  a unique  name-binding 
policy.  For  example,  consider  the  program  fragment 


t- 

f 

! 

I 


integer  k-10; 
begin 

vector  X[l:k]; 
integer  k-3; 


In  the  declaration  of  the  vector  "X”,  there  is  a question  about  which  "k"  should  be  used  to 
define  its  upper  bound.  The  semantics  of  some  languages  specify  that  the  value  of  the 
variable  "k”  defined  at  the  outer  block  level,  i.e.,  10,  should  be  used;  other  languages  specify 
that  it  is  the  innermost  definition,  i.e.,  "integer  k>3",  which  should  be  used.  To  accommodate 
the  second  of  these  schemes  requires  that  a full  lexical  analysis  pass  be  performed  before 
any  name  binding  (symbol  table  construction)  is  done. 

In  order  to  make  our  abstraction  useful  on  this  pure  lexical  pass,  as  well  as  later  when 
the  full  symbol  table  is  constructed,  we  shall  define  it  as  a mapping  between  "things"  and 
integers.  In  a simple  system  the  "things"  will  be  identifiers  and  the  integers  will  probably  be 
indices  into  the  vector  of  attributes  described  above.  In  a more  complex  system,  the  initial 
lexical  pass  may  use  the  abstraction  to  convert  identifiers  into  integers;  these  integers  may  in 
turn  be  the  "things"  mapped  into  symbol  table  indices  during  a later  pass.  An  example  of  the 
use  of  the  abstraction  will  be  given  later  to  help  clarify  this  point;  for  the  moment  the  reader 
may  simply  assume  that  the  "things"  are  identifiers. 

Summarizing,  then,  our  abstraction  shall  provide: 

(a)  A block-structured  mapping  from  "things"  to  integers. 

(b)  A set  of  six  operations  to  instrt  a new  "thing",  to  lookup  the  integer 

associated  with  a specific  "thing",  to  test  whether  a specific  "thing"  is 
dofinod  at  the  current  block  level,  to  enter  and  to  leave  a block  'evel,  and  to 
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test  whether  the  mapping  is  fuU,  i.e.,  whether  there  is  room  for  another 
"thing". 


The  Symbol  Table  Abstraction 


The  preceding  section  provides  an  informal  description  of  the  symbol  table  abstraction; 
in  this  section  we  shall  be  more  precise.  Specifically,  the  specifications  part  of  the  form  called 
"symtab"  is:^ 


form  svmtab<T:form<  <-,“,hash(T,k;integer)  returns  x:integer  pra  (k>0)  post  (OSx<k’)  >, 
m,n:integer)  - 
beginform 
specifications 

requires  nil  a mil; 

let  symtab  = <block:integer,  assoc:{<s:T,bl:integer,ui:integer>)>; 
invariant 

cardinalitytassochn 
A l<ui<n  A l<bl<block 

A (tj,t2  ^ assoc  3 (tj.s-t2.s  a tj.bl-t2.bl  » tj.ui-t2.ui)); 
initially  symtab  - <!,{}>; 
functions 

defined(st:symtab,str:T)  returns  t:boolean 
post  t - 3i  ft  <str,st.block’,i>  ( st.assoc, 
insert<st:symtab,str:T)  returns  i:integer 

pre  cardinalitytst. assoc)  < n a -.defined(st,str) 
post  st  - <st.block’,  st.assoc’  U {<str,st.block’,i>}>, 
lookup(st;symtab,str:T)  returns  x:integer 

post  if  3 y t st.assoc  ft  [y.s-str  a Vz  ( st.assoc,  z.s-str  p z.bl  i y.bl] 
then  X - y.ui 
else  X - 0, 

enterblock($t:symtab) 

post  st  - <st.block’4.1,st.assoc’>, 
leaveblock(st:symtab) 
pre  st.block  > 1 

post  st  - <st.block’-l,  st.assoc’  - {<s,x,ui>  ft  xist.block’)>. 


^ A primed  variable  (e.g.,  k’)  represents  the  value  of  that  variable  prior  to  the 
execution  of  an  operation.  To  shorten  the  pre.  post,  jn,  and  pjit  conditions  in  our  papers,  we 
often,  by  convention,  omit  assertions  about  variables  which  are  completely  unchanged.  Thus 
for  example,  we  have  omitted  st  - st*  from  the  post  condition  of  <Ufin»d. 
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fuli($t:symtab)  returns  t:boolean 

post  t - (cardinality(st.assoc)  - n); 


I 

I 


( 

t 


Note  that,  abstractly,  a symbol  table  consists  of  a pair:  an  integer,  "block",  and  a set, 
"assoc".  The  integer  denotes  the  current  block  level,  has  the  initial  value  1,  and  is  altered 
only  by  the  operations  enterblock  and  teavebtock.  The  set,  initially  empty,  consists  of  triples 
containing  the  "thing"  defined,  the  block  level  at  which  it  was  defined,  and  the  unique  integer 
("ui")  associated  with  the  <thing,block  level>  pair. 

The  parameters  of  the  form  specify  the  type,  "T"  (usually  strings),  of  "things"  to  be 
entered  in  the  table,  and  the  maximum  number,  "n",  of  simultaneous  entries  permitted.  The 
parameter  "m"  is  a bit  more  difficult  to  explain,  and  we  shall  for  a moment  defer  it,  together 
with  the  discussion  of  the  required  rights  of  T. 

Since  the  symbol  table  contains  only  currently  defined  things,  the  block  level  of  each 
entry  must  be  legitimate  (e.g.,  between  1 and  the  current  value  of  "block").  Further,  since  a 
maximum  of  n entries  is  allowed,  the  "associated  integer"  must  lie  between  1 and  n.  Tfie 
clause  and  the  abstract  invariant  express  these  restrictions  (the  last  line  of  the  invariant 
expresses  the  uniqueness  of  the  integer  associations).  The  remainder  of  the  specifications 
states  that  the  initial  symbol  table  has  a block  level  of  1 and  an  empty  "assoc"  set,  and  then 
lists  the  symbol  table  functions  and  their  abstract  pre  and  post  conditions. 

Now,  let  us  return  to  the  issue  of  the  parameter  m and  the  required  rights  on  T.  As 
may  be  seen  from  the  requires  clause  of  the  specifications,  the  only  requirement  on  m is  that 
its  value  be  strictly  positive;  it  does  not  enter  into  any  of  the  other  parts  of  the  formal 
specification.  Hence,  one  may  properly  conclude  that  its  precise  value  is  immaterial  and  the 
abstraction  will  function  correctly  with  any  positive  value. 

The  value  of  m does,  however,  affect  the  performance  of  the  abstraction.  Neither 
Alphard  nor  other  languages  with  similar  goals  have  yet  found  an  appropriate  way  to  specify 
performance  properties.  In  practical  systems,  of  course,  such  properties  are  of  paramount 
importance.  Since  we  now  have  no  formal  way  of  specifying  them,  we  must  give  a small  peek 
into  the  representation  in  order  to  explain  the  significance  of  m.  (Indeed,  the  need  to  have  m 
and  the  hash  function  name  in  the  specifications  has  essentially  revealed  the  techniques  used 
in  the  implementation  of  the  abstraction.)  The  representation  uses  a hash  table,  with  collisions 
resolved  by  chaining,  and  m specifies  the  size  of  this  table,  i.e.,  the  number  of  values  that  the 
hash  function  may  assume.  Although  any  positive  value  of  m will  work,  larger  values  will  tend 
to  provide  faster  searches  at  the  expense  of  some  additional  storage. 

In  addition,  the  value  of  m may  affect  the  distribution  of  "hits"  on  any  particular  hash 
table  entry;  see  [Knuth73]  for  a discussion  of  hashing  functions  and  their  properties.  We  will 
not  discuss  these  prsperties  here,  but  note  that  the  form  T which  defines  the  things  stored  in 
the  symbol  table  is  required  to  provide  a hashing  function  which,  given  an  object  of  type  T 
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and  an  integer  k,  returns  an  integer  in  the  range  0 to  k-1.  Thus,  an  appropriate  choice  of  m 
depends  in  part  on  the  properties  of  this  function. 


Implementation  of  Symbol  Table 


i 


In  choosing  the  implementation  of  the  symbol  table  abstraction,  we  have  been  careful  to 
pick  a practical  one;  it  is,  in  fact,  one  which  is  used  in  several  commercial  compilers.  We  chose 
to  do  this  rather  than,  for  example,  to  use  a direct  implementation  in  terms  of  sets  (e.g.,  the 
i 'eset  form  defined  in  [Shaw76b]).  We  have  done  this  in  order  to  emphasize  that  both  the 
I-  n;  lage  and  verification  methodology  are  intended  to  be  used  for  practical,  production  quality 
-/stems.  The  more  direct  implementation,  and  also  its  proof,  would  have  been  straightforward 
and  clear.  However,  it  would  not  have  been  a production  quality  implementation  and  thus 
would  not  have  been  useful  in  a real  system.  We  shall  comment  on  this  point  further  in  the 
conclusion,  but  we  feel  strongly  that  language,  methodology,  and  verification  must  respond  to 
the  requirements  of  practical,  efficient  systems. 

We  shall  obtain  the  implementation  in  two  steps.  We  shall  define  an  intermediate 
abstraction  (form)  in  the  process  of  obtaining  the  complete  implementation.  This  intermediate 
abstraction  will  support  a restricted,  but  not  uncommon,  style  of  list-processing. 

Now,  whenever  a system  implementation  is  described,  one  is  faced  with  a presentation 
problem:  whether  the  description  should  be  "top-down"  or  "bottom-up".  Both  have 

advantages.  In  this  case  we  have  chosen  to  make  the  presentation  predominantly  top-down  — 
primarily  to  emphasize  that  the  implementation  of  lower  level  abstractions  is  irrelevant  to  the 
correctness  of  the  higher  level  ones.  The  next  paragraph,  however,  is  an  exception  to  the 
predominant  flavor  of  the  presentation;  it  describes  the  implementation  of  the  symbol  table  in 
low-level  terms,  as  it  will  exist  after  compilation  of  the  forms.  It  is  included  for  those  of  us 
(including  the  authors)  who  still  need  concrete  representations  to  aid  their  reasoning;  purists 
may  simply  skip  the  next  paragraph. 

The  symbol  table  will  be  implemented  as  a hash  table  with  explicit  entries  for  the 
symbol  and  its  declaration  block  level,  but  an  implicit  encoding  of  the  integer  mapping.  Hash 
collisions  are  resolved  by  associating  a linked  list  of  symbol  table  entries  with  each  value  of 
the  hash  function.  Each  new  entry  is  inserted  at  the  head  of  the  appropriate  list.  The  entries 
on  the  lists  are  therefore  ordered  by  block  level  (innermost  block  first).  To  find  the  innermost 
instance  of  a symbol,  lookup  need  only  perform  a linear  search  of  the  list  associated  with  the 
hash  value  of  the  symbol;  the  first  instance  of  the  symbol  in  the  list  is  necessarily  the  one 
declared  at  the  innermost  block  level.  It  is  a simple  matter  for  leaveblock  to  delete  the  proper 
entries  from  the  heads  of  these  lists. 

The  implementation  of  symtab  presumes  the  existence  of  a form  called  "condis" 
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(collection  of  named,  disjoint  integer  sequences).  The  explanation  of  the  symtab 
implementation  will  require  that  we  first  understand  (i.e.,  specify)  condis.  Although  condis  is 
intended  to  support  a group  of  linear  lists,  its  abstract  specification  is  stated  in  terms  of  more 
mathematically  tractable  entities,  namely  sets  and  sequences.^  The  verification  of  symtab  will 
use  the  abstract  specification  from  condis  but  nothing  else.  The  verification  of  condis  will  be 
independent  of  symtab  and  its  verification.  The  specifications  part  of  condis  is: 


form  condis(n,m:integer)  = 

beginform 

specifications 

requires  nil  a mil; 

let  condis  •«  L;{sqj:<ej^,ej2,  . . . , ejp,.>  | OsiSm-1  A ej|^  U integer}; 
invariant  l<ej(^<n  a Vi,j  < [0..m-l](em  =e;|^  p i=j  a k|=k2): 
initially  Vi  ( [0..m-l]  sqj  » <>;  12 

functions 

xtnd(s:condis,i:integer)  returns  j:integer 

pre  i < [0..m-l]  a SIGMAj^j-Q  length{s.sqj)<n, 

post  s.sqj  = <]>~s.sqj’,  ! note  j is  a new  value  not  in  any  sq  (by  Ig) 

del(s:condis,  i,j:integer) 

pre  s.sqj  = < . . . , j,  ...  > A ic[0..m-l] 
post  s.sqj  = <j,  ...  >, 
delall(s:condis,i:integer) 
pre  i < [0..m-l  ] 
post  s.sqj  = <>, 

full(s:condis)  returns  t:boolean 

post  t = SlGMAj([Q  length(s.sqj)  = n; 
generator  indis(s:condiG,i:integer)  extends  x:integer 
requires  0<i<m-l 
[et  indis  = s.sqj  where  indis?^<>  p 

(indis  “ c~<x>~d  and  c,  <x>,  and  d are  disjoint); 
rule  ford,  x,  <s,i>,  ST)  = 

premise  s.spj=c'>'<x>'-d  a 1(c)  {ST}  l(c'^x>); 
rule  firsUP.  x,  <s,i>,  /?,  Sj,  $2.  Q)  “ 

premise  s.sqj>=c'^x>~d  a P a Vy  < c(--/2(y))  a fl{x}  {Sj}  Q, 
premise  P a Vy  < s.sqj-'^(y)  {S2}  Qi 
auxiliary  predicates 

follows(s;condis,i,j:integer)  3k  st  sq|^  «<...,  i, ...,  j,  ...  >, 
mbr(s:condis,i,j:integer)  sqj  »<...,  j, ...  >; 


A condis  is  abstractly  described  as  a set  of  precisely  m sequences  of  integers;  these 


^ Definitions  and  properties  of  sets  appear  in  [HalmosSO]  and  those  of  sequences  in 
[Wulf76a,b]. 
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sequences  are  named  sqQ  through  sq^.j^.  The  abstract  invariant  asserts  that:  (1)  each  integer 
in  any  of  the  sequences  lies  in  the  range  1 to  n and  (2)  a particular  integer  appears  as  a 
sequence  element  at  most  once  in  the  entire  set  of  sequences.  From  these  two  facts  we  can 
observe  that  the  sum  of  the  lengths  of  the  sequences  is  at  most  n;  moreover,  in  the  case  that 
this  sum  is  n,  each  of  the  integers  1 through  n will  appear  (precisely  once)  in  one  of  the 
sequences. 

As  a practical  matter,  each  of  the  sequences  in  the  condis  will  represent  a linear  list; 
specifically,  sqj  will  be  associated  with  the  value  i produced  by  the  hash  function.  The 
sequence  elements  will  be  the  (integer)  indices  into  a vector  of  information  within  symtab;  thus 
the  sequence  sqj  (and  the  corresponding  entries  in  the  vector  of  information)  will  represent 
the  linear  list  of  triples  in  the  abstract  "assoc"  set  of  symtab  which  have  the  hash  function 
value  i. 

Four  functions  and  a generator  are  provided  by  the  condis  form.  Function  xtnd  extends 
the  head  of  a specified  sequence  by  one  element;  the  abstract  invariant  prevents  this  integer 
from  being  one  which  already  appears  in  some  sequence.  Function  del  permits  the  initial 
elements  of  a specified  sequence  to  be  deleted,  and  function  detail  permits  all  the  elements  of 
a specified  sequence  to  be  deleted.  Function  full  tests  whether  all  of  the  integers  already  are 
in  some  sequence.  Generator  indU  produces  the  elements  of  a specified  sequence  in  order, 
starting  with  the  head.  The  specification  of  condis  also  gives  two  auxiliary  predicates  (follows 
and  nihr).  These  may  be  used  in  proofs,  but  are  not  actually  implemented  as  executable 
functions;  they  should  be  viewed  as  an  extension  to  the  abstract  vocabulary. 

At  first  sight,  the  condis  abstraction  may  seem  unusual;  however,  we  chose  to  define  it 
in  this  way  for  two  reasons; 

- By  using  integers  to  denote  elements,  we  can  obtain  an  efficient  encoding  of  the 

unique  integer  mapping  required  by  symtab.  This  encoding  is  one  which 
might  be  selected  in  actual  practice. 

- This  definition  allows  us  to  skirt  the  issue  of  pointers  (references)  for  purposes 

of  this  paper, ^ 

Now  we  can  present  the  complete  definition  of  the  symtab  form. 


^ As  moi  who  have  followed  the  recent  literature  on  programming  methodology 

and  verification  aware,  the  presence  of  references  (unconstrained  pointers)  in  a 

programming  language  interferes  with  our  ability  to  understand  and  verify  programs  that  use 
them.  While  we  believe  we  have  made  significant  progress  in  Alphard  toward  resolving  the 
problems  introduced  by  the  unconstrained  pointer,  we  will  not  complicate  this  paper  with 
pointer  issues. 
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formi  symtab(T;form<  <-,“.hash(T,k:integer)  returns  xHnteger  pre  (k>0)  post  (0<x<k’)  >, 
m,n:integer)  = 
beginform 
specifications 

requires  n>l  a mil; 

1^  symtab  = <block:integer,  assoc:{<s:T,bl:integer,ui:integer>)>; 
invariant 

cardinality{assoc><n 
A l<ui<n  A l<bl<block 

A (t^,t2  « assoc  3 (t2.s=t2.s  a t2.bl=t2.bl  e t|.ui“t2.ui)); 
initially  symtab  = <!,{}>; 
functions 

defined(st:symtab,str:T)  returns  t:boolean 
post  t = 3i  ft  <str,st.block’,i>  c st.assoc, 
insert<st:symtab,str:T)  returns  iiinteger 

pre  cardinality(st.assoc)  < n a -defined{st,str) 
post  st  = <st.block’,  st.assoc’  u {<str,st. block’, i>)>, 
lookup(st:symtab,str:T)  returns  x;integer 

post  if  3 y ( st.assoc  st  [y.s=str  a Vz  € st.assoc,  z.s=str  a z.bl  S y.bl] 
then  X “ y.ui 
else  X ■=  0, 

enterblock(st:symtab) 

post  st  = <st.block’+l,st.assoc’>, 
leaveblock(st. symtab) 
pre  st. block  > 1 

post  st  = <st.block’-l,  st.assoc’  - {<s,x,ui>  st  x>st.block’}>, 
fulKst-.symtab)  returns  t;boolean 

post  t = (cardinality<st.assoc)  = n); 


representation 

unique 

blvl:  integer, 

info:  vector(recordfs:T,bl:integer),I,n), 
as;  condis(n,m) 
init  blvl  ♦-  Ij 

refi(as,info,blvl)  = <blvl,  {<info[i].s,info[il.bl,i>  | 3j  ( [0..m-l]  ft  mbr(as,j,i)}>; 
invariant 

(mbr(as,i,j)  d hash(info[j].s,m)  = i) 

A (follows<as,i,j)  3 blvl  i info[i],bl  i info[j].bl  i 1 a {info[i>info[j]  a i-j)) 


implementation 

bo^  defined  out  (t  = 3j  ft  st.info[j]»<str,st.blvl>  a mbr(st.as,hash(str,m),j)) 
first  j:indis(st.as,hash(str,m))  suchthat  st.info[j].s-str 
then  t *-  st.infofjj.bl-st.blvl  else  t ♦-  false; 


r 
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body  insert  in  --fulKst.as)  a -defined(st,str) 

gut  (st.info[i]»<str,st.blvl>  A sqj^a^htstr.m)  “ ^>>"sq’hash(str,m>)  ‘ 
beein 

i <-  xtnd(st.as,hash(str,m))| 
st.info[i]  <-  <str,st.blvl>; 
end; 

body  lookup  gut  (x»0  o (j  < [i.,n]  a 3i  i [0..m-l](mbr(st.as,i,j))  o st.info[j].s  / str))  a 
(x>0  o st.info[x].s»str  A (st.info[j].s»str  o j-x  v st.info[x].bl  > st.info[j].bl))  - 
^i>'st  j:indis(st.as,hash(str,m))  suchthat  st.info[j].S“str 
then  X *-  i else  x ♦-  0; 

body  enterblock  gut  (st.blvl  » st.blvT  + 1)  - 
st.blvl  <-  st.blvl  + l; 


} 

I ; 


body  leaveblock  in  st.blvl  > 1 

out  (st.blvl  = st.blvl’  - 1 A (j  < [l..n]  a I ( [0..m-l]  o 

(mbr(st.as,i,j)  h mbr(st.as’,i,))  a st.info[j].bl  < st.blvl’)))  - 

begin 

st.blvl  4-  st.blvl-1; 

for_  i:  upto(0,m-l)  ^ ! the  generator  upto  is  defined  in  [Shaw76b] 

first  j:indis(st.as,i)  suchthat  st.info[j].bl  S st.blvl 
then  del(st.as,i,j)  else  delall(st.as,i); 

end; 

body  full  gut  (t  - SIGMAj^rQ  length(s.sq;)  - n)  ■ 
t <-  full(st.as); 
endform 


Note  that  the  representation  of  a symtab  consists  of  three  objects:  (1)  blvL,  an  integer, 
is  a cfirect  representation  of  the  abstract  entity  block,  and  is  initialized  to  1.  (2)  info  is  a 
vector  of  records  which  hold  the  "thing"  (usually  a string)  and  the  block  level  at  which  it  was 
declared.  Each  of  these  records  is,  in  effect,  one  of  the  triples  in  the  abstract  "assoc"  set;  the 
third  element  of  the  triple,  the  unique  integer,  is  not  explicitly  represented  — rather,  it  is 
implicitly  encoded  as  the  index  of  this  record  in  the  vector.  (3)  <u  is  a condis,  and  as 
explained  above,  it  represents  a set  of  lists  of  indices  into  this  vector  of  records;  each  such 
list  is  uniquely  associated  with  a hash  function  value. 

A point  which  may  not  be  obvious  is  worth  noting.  It  is  rare  that  all  info  entries  will  be 
in  use;  we  thus  have  a potential  problem  in  maintaining  the  free  storage  of  this  vector.  This 
problem  is  handled  by  the  condis  abstraction.  The  uniqueness  of  the  integers  in  condis 
sequences  guarantees  that  no  info  entry  will  be  used  simultaneously  by  different  members  of 
assoc.  In  essence,  the  Integer  values  which  are  in  the  condis  sequences  correspond  to 

i 

i 
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occupied  entries,  and  all  other  integers  in  the  range  1 to  n correspond  to  unoccupied,  or  free, 
entries.  Specifically,  the  abstract  invariant  of  condis  and  the  post  condition  of  xtrud  together 
provide  a safe  allocation  of  new  info  entries.  Similarly,  del  and  detail  provide  a safe 
deallocation  mechanism. 

To  illustrate  the  operation  of  the  implementation,  consider  the  interaction  of  the  bodies 
of  insert  and  lookup.  When  a new  symbol  is  to  be  inserted,  we  first  invoke  the  condis 
operation  xtnd.  This  has  the  effect  of  extending  the  head  of  the  sequence  associated  with  the 
hash  value  of  the  symbol  by  a new,  unique,  integer.  This  integer  is  then  used  as  the  index 
into  the  vector  info  and  the  symbol  and  current  block  level  are  recorded  in  this  entry.  When 
a later  lookup  is  performed  on  this  symbol,  the  indis  generator  is  used  to  find  the  first 
integer,  j,  in  the  sequence  associated  with  the  hash  value  of  the  symbol  for  which  "info[j].s" 
matches.  Since  xtnd  extends  the  sequence  at  its  head,  this  match  is  necessarily  the  most 
recently  declared  instance  of  the  symbol. 


Verification  of  the  form  Symtab 

A form  is  verified  by  proving  four  properties  as  described  in  [Wulf76a,b]  and 
summarized  in  Appendix  A.  As  promised  earlier,  the  verification  below  uses  only  the  abstract 
specification  of  the  form  condis,  including  the  auxiliary  predicates.  The  implementation  of 
condis  is,  as  desired,  irrelevant  to  symtab.  All  uses  of  the  generator  indis  satisfy  the 
independence  assumption  provided  that  in  leaveblock  we  regard  both  the  then  and  else 
clauses  as  being  outside  the  first  generator.^ 


F or  the  form 

1.  Representation  validity 

Show;  lj.(as,info,blvl)  o lgtreptas,info,blvl» 

Proof;  cardinality(assoc)  < n follows  from  Ig  for  condis,  namely,  l<ej(^<n 
and  no  duplicate  ej|^’s  means  at  most  n elements  in  assoc.  The  relation 
l<ui<n  holds  because  of  mbr  in  the  rep  function  and  l<ej|^<n  in  Ig  for 
condis.  The  relation  l<bl<bloch  follows  by  setting  j»i  in  follows(as,i,j) 
in  Ij,.  To  show  uniqueness  in  assoc,  first  note  that  identical  s and 


^ Strictly  speaking,  this  violates  the  definition  of  the  first  statement  in  [Shaw76b],  a 
definition  which  we  must  modify  to  permit,  for  example,  finalization  statements  and  the 
leaveblock  usage.  We  must  also  weaken  the  independence  assumption.  With  the  strict 
interpretation,  however,  an  ad  hoc  argument  shows  that  there  are  no  problems  in  this  case 
because  indis  does  not  modify  the  generated  sequence  and  no  further  generation  is  attempted 
after  the  then  and  else  clauses. 
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identical  bl  means,  letting  hashttl.s.m)  - hash(t2.s,m)  - k,  that 
mbr(as,k,tl.ui)  and  mbr(as,k,t2.ui),  whence  we  have  either 
follows(as,tl.ui,t2.ui)  or  follows(as,t2.ui,tl.ui).  In  either  case,  since 
info[tl.ui]=info[t2.ui],  then  tl.ui  - t2.ui  as  required.  The  converse  of 
the  uniqueness  clause  holds  since  Ig  for  condis  means  no  duplicates. 

2.  Initialization 

Show;  n^l  A mil  { blvl«-l  ) <!,{}>  = rep(as.info.blvl)  A 1^ 

Proof:  This  holds  since  initially  of  condis  says  each  sqj-o,  i.e.,  -•mbr(as,j,i) 
and  -•follows(as,i,j).  Note  that  nil  a mil  permits  the  declaration 
as:condis. 

For  the  function  defined 

3.  Concrete  operation 

Show;  Ij,  { first  j:indis(st.as,hash(str,m»  suchthat  st.info[j].S“str 
then  t «-  st.info[j].bl=st.blvl  else  t«-false  ) a 

Proof:  holds  since  it  is  unchanged.  Indis  may  be  called  since 

0<hash(str,m)<m.  By  the  first  term  of  str  can  only  be  located  from 
®‘^hash(str,m)-  then  clause,  the  second  term  of  I^,  gives 

(Note  that  mbr(st.as,hash(str,m),j)  holds  by  the  definition  of  indis.)  For 
the  else  clause  str  was  not  located  from  sqpiggj^^gj^  whence  t is 
false  as  requited. 

4a.  holds 
is  true 

4b.  /(post  holds 

Show;  Ij,  A /tpui  3 t ■=  3i  it  <str,st.block’,i>  C st.assoc 

Proof:  If  t is  true  in  /(?Qut>  <st.info[j].s,  st.info(j).bl,j>  ■*  <str,st.block’,i> 
< st.assoc,  i.e.,  choose  i to  be  j.  If  t is  false  in  /?out*  *^®  ' 

and  t is  false  as  required. 

F or  the  function  insert 

3.  Concrete  operation 

Show:  /?j^  A 1^  { i<-xtnd(st.as,hash(slr,m))j  st.info[i]+-<str,st.blvl>  } a 1^ 

Proof:  The  pre  of  xtnd  holds  because  hash(str,m)  ( [0..m-l]  and  because 
-•full(st.as)  means  cardinality(st.assoc)  < n whence  the  SIGMA  term  < n. 
The  first  term  of  is  clear.  Since  the  hash(str,m)^^  sequence  of  as 

is  extended,  sqhgsh(str,m>  “ ^'='"'S4’hash(str.m) 
appended  new  element.  The  first  term  of  1^  follows  by  the  call  to 
xtnd  and  st.infoLiJ.s-'Str;  the  second  term  of  I^,  follows  by  Ip  and 
-■defined(st,str),  i.e.,  str  is  not  defined  at  the  current  block. 

4a.  holds 

Show:  Ip  A cardinality(st.assoc)<n  a -definedfst.str)  3 /!?j^ 

Proof:  cardinality(st. assoc)  < n means  ->full(st.as). 


1 
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'^post 

Show;  A /Sp|,g  A 3 f^post 

Proof:  The  new  triple  <st.info[iis,st.info[i].bl,i>  is  added  to  st.assoc. 

For  the  function  lookup 

3.  Concrete  operation 

Show:  Ip  { first  j:indis(st.as,hash(str,m»  suchthat  st.info[j].s»str 
then  x«-j  else  x«-0  } a Ip 

Proof:  Ip  is  unchanged.  As  in  the  operation  defined,  str  can  only  be 
located  from  sqhash(str,m>-  indis,  j ( [l..n].  Hence  only  the  else 
clause  makes  x=0  and,  as  required  in  this  case,  j ( [l.n]  a 3i  ( 
[0..m-l]<mbr(st.as,i,j))  o st.info[j].SF^str.  For  the  then  clause,  the  first 
term  after  x>0  holds  by  the  suchthat  clause.  For  the  second  term 
after  x>0,  suppose  jj^x.  Using  the  second  term  of  Ip  (note  that 
follows(st.as,x,j)  holds)  rules  out  the  possibility  that 
st.info[x].bl“st.info[j].bl  since  otherwise  j*x.  Hence  st.info[x].bl  > 
st.info[j].bl. 

4a.  /3j„  holds 
is  true 

/'^post 

Show:  Ip  A ^ ^post 

Proof:  X“0  means  -3y  it  y.s«str.  x>0  means  x - y.ui,  i.e.,  y » 
<st.info[j].s,st.info[j].bl,j>. 

For  the  function  enterblock 

3.  Concrete  operation 

Show:  Ip  { st.blvl  ♦-  st.blvl+1  } a Ip 

Proof:  is  clear.  Since  st.blvl  increases.  Ip  still  holds. 

4a.  holds 
is  true 

4b.  /(?po5t  holds 

Show:  Ip  A 3 

Proof:  st.block  - st.blvl  « st.blvl’+l  » st.block’+l  and  st.assoc  ■*  st.assoc’. 

For  the  function  leaveblock 

3.  Concrete  operation 

Show;  A Ip  { body  ) a Ip 

Proof:  st.blvl  - st.blvl’-l  is  clear.  By  the  fsL  statement  each  sqj  for  i € 
[0..m-l]  is  adjusted  by  the  first  statement.  For  each  of  indis,  del,  and 
delall,  we  have  the  pre  condition  i i [0..m-l]  by  the  for  statement. 
The  other  part  of  pre  of  del,  mbr(st.as,i,j),  holds  by  indis.  In  the  then 
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case,  del(st,as,i,j)  deletes  all  entries  in  sqj  up  to  but  not  including  j. 
Because  j is  the  first  j with  st.info[j].blSst.blvl<st.blvl’,  the  block  level 
ordering  asserted  by  ensures  /?out-  else  case  all 

st.info[j].bl>st.blvl  whence  spj  should  become  <>,  which  delall  does, 
/^out  fol'o'ws  since  st.infolj].bl<st.blvl’  a -■mbr<st.as,i,j).  In  both  the  then 
and  else  cases,  still  holds  because  the  lists  only  get  shorter  and 
st.blvl>l  on  entry. 

4a.  /3jp,  holds 

Show:  Ij,  A st.block  >1  = st.blvl>l 

Proof:  In  the  rep  function,  st.block  and  st.blvl  correspond. 

'^post 

Show:  I^  A /ipfQ  A 3 /^post 

Proof:  Since  st.blvl=st.blvr-l,  we  have  st.block=st.block’-l  as  required.  By 
^out  function,  st.assoc-st.assoc’  - {<s,x,ui>  st  xSst.block’). 

For  the  function,  full 

3.  Concrete  operation 

Show:  Ij.  { tHulKst.as)  } a I^ 

Proof:  is  exactly  the  post  condition  of  full  in  condis.  is  unchanged. 

4a.  holds 

/Ijf,  is  true 

^post 

Show:  1^  A p 

Proof:  t “ (SIGMAj  ^ length(s.sqj)  «>  n)  • (cardinality(st.assoc)  - n). 

QEO 
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As  discussed  earlier,  the  abstract  representation  of  condis  is  a set  of  precisely  m 
sequences  of  integers.  The  integers  in  these  sequences  are  all  in  the  range  1 to  n,  and  a 
particular  integer  appears  at  most  once  in  some  sequence. 

As  one  might  expect,  the  sequences  will  be  represented  by  singly  linked  lists.  In  fact 
we  shall  use  an  integer  vector.  It  (lor  link-table),  to  store  all  of  the  lists  which  represent 
sequences  in  a condis.  The  fact  that  an  index  i into  It  is  in  the  k^^  position  of  such  a list  will 
represent  the  fact  that  i appears  in  the  k^*^  position  of  the  corresponding  abstract  sequence. 
A separate  vector,  sq,  of  length  m,  is  used  for  the  heads  of  the  lists.  In  all  cases,  zero,  which 
is  not  a legal  condis  sequence  element,  is  used  to  indicate  the  end  of  a list)  thus,  in  particular, 
if  sq[j]“0,  the  condis  sequence  is  empty A separate  list  of  those  integers  which  are  not 
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currently  members  of  any  sequence  is  also  maintained,  and  the  head  of  this  list  is  maintained 
in  the  simple  variable  frae.  The  following  diagram  illustrates  one  possible  configuration  of  a 
condis  object  which  has  been  declared  with  m-3  and  n-10: 


form  condis(n,m:integer)  - 

beeinform 

specifications 

requires  n^l  A mSl; 

let  condis  •*  L:{sqj:<ej|,ej2,  . . . , ejp,.>  | 0<i<m-l  a ej^  Ls  integer}; 
inyariant  l^ej^<n  A Vi,j  < [0..m-l](ej,^  -ei^  a i-j  A kj-k2>; 
initially  Vi  C [0..m-l]  sqj  = <>; 
functions 

xtnd<s:condis,i:integer)  returns  j:integer 

pre  i < [0..m-l]  a SlGMAj^^Q  length(s.sqj)<n, 

post  s.sqj  “ <]>'vs.sqj’,  ! note  j is  a new  value  not  in  any  sq  (by  Ig) 

deKsxondis,  i,j:integer) 

pre  s.sqj  - < . . . , j,  ...  > a i([0..m-l] 
post  s.sqj  » <j,  ...  >, 
delall(s:condis,i:integer) 
pre  i « [0..m-l] 
post  s.sqj  - <>, 

full(s:condis)  returns  t:boolean 

P.pst  t - SIGMAj^jQ  length(s.sqj)  - n; 


^ We  can  now  explain  why  the  function  detail  is  not  redundant.  The  knowledge  that 
zero  ends  a list  is  private  to  condis,  and  therefore  it  is  not  known  in  symtab.  Hence,  in  the 
i^ody  of  leaveblock  of  symtab,  the  operation  "delall(as,i)"  cannot  be  replaced  by  "del(as,i,0)". 
To  do  so  would  violate  the  pre  condition  of  del  because  if  j is  a member  of  sqj,  it  means  jfcl. 
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generator  indjs(s;condi8,i:integer)  extends  xtinteger 
requires  Osism-1 
let  indis  ■ s.sqj  where  indis»«>  a 

(indis  ■ c'^x>*^d  and  c,  <x>,  and  d are  disjoint): 
rule  ford,  x,  <s,i>,  ST)  •• 

premise  s.sqj -c~<x>'*'d  A 1(c)  {ST}  I(c'^x>): 
rule  firsUP.  x,  <s,i>,  /3,  Sj,  $2,  Q) 

premise  s.sqj -c'^x>'*d  A P a Vy  ( c(-/?(y))  A fi{x)  {Sj}  Q, 
premise  P A Vy  ( s.sqj-/?(y)  {S2}  Qj 
auxiliary  predicates 

follows(s:condis,i,j:integer)  «j|f  3k  *t  sq|^  •<...,  i, ...,  j, .. . >, 
mbr(s:condis,i,j:integer)  sqj  -<...,  j, ...  >; 

representation 

unique 

sq:  vector(integer,0,m-l), 

It:  vector(integer,l,n), 
free:  integer 

init  begin  free  <-  1;  for  i:upto(l,n-l)  ^ lt[i]  «-  i+1;  lt[n]  *-  0; 
for  i:upto(0,m-l)  ^ sq[i]  ♦-  0 end; 
re£(sq,lt,free)  - {SQj  | 0<i<m-l}  where 
if  sq[i]  - 0 then  SQj  » <>  else 

if  sq[i]  - Pi  A (Vj  i [l..k-l]  lt[pj]-pj+i)  A lt[p|^]-0  then  SQj  - <Pi, . . . ,P|^>; 
invariant 

0 < free  < n 

A Vj  < [0..m-l]  0 < sq[j]  <,  n 
A Vk  < [l..n]  0 i lt[k]  5 n 

A {free,  sq[j],  lt[k]}  = {m+1  O’s,  1,  2, n)  ! this  term  is  a multiset  equality 
A Vi  € [l..n](succ(free,i)  xor  3!j(succ(sq[j],i») 

where  succ(i,j)  i-j  v (i»<0  cand  succ(ltti],j)): 

implementation 

body  xtnd  m s.freei^O  a i c [0..m-l] 

out  (succ(s.free’,j)  a succ(s.sq[ilj)  a s.sq[i]-j  a s.lt[j]  ■ s.sq’p])  - 
begin 

j «-  s.free;  s.free  *-  s.lt[j]; 
s.lt[j]  ♦-  s.sq[ij  s.sq[i] «-  j; 
end; 


¥ 


m 
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Implementation  of  the  form  Condis 


body  del  in  succ(s.sq[i],j)  a i < [0..m-l]  a j i [0..n]  out  (s.sq[i]-j)  - 
if  s.sq[i]i<j  then 

begin  local  krinteger; 
k «-  s.sq[i]; 

while  s.lt[k]  j ^ k «-  s.lt[k]; 

s.lt[k]  *-  s.freej  s.free  *-  s.sq[i];  s.sq[i]  *-  y, 

endi 


body  delall  [n  i ( [0..m-l]  out  (s.sq[i]»0)  = 

s.del(s,i,Oh  ! a call  to  the  concrete  body  del,  not  the  abstract  function  del 


body  full  Old  (t  * (s.free*0)) 
t «-  s.free=0; 


formbody  indis  ■» 

beginform 

representation 

rep(s.sg.s.lt.i.x)  » 

if  s.sq[i]  “ 0 then  <>  else 

if  X = 0 then  c~d  where  c “ s.sqj  and  d ■•  <>  else  c^x>^d 
^b.ere  c - <p^, . . p^.j>,  x-o^,  d - p^>, 

Pi  “ s.sq[i],  s.lt[p,^]  - 0,  and  (Vj  < [l..k-l]  s.lt[pj]  - pj^j); 
invariant  true; 
implementation 

body  &init  out  (x=s.sq[i]  a (&b  ■ s.sq[i]»<0))  « 

(x  «-  s.sq[i]j  &b  «-  x><0)i 


body  &next  in  succ(s.sq[i],x)  A x»<0  out  (x«s.lt[x’]  a (&b  • s.lt[x’]j‘0)) 
(x  ♦-  s.lt[x];  &b  «-  x»<0)j 
endform 


endform 


The  implementation  of  the  four  operations  in  condis  should  be  fairly  obvious,  xtnd 
merely  removes  an  entry  from  the  free  list  and  places  it  at  the  head  of  the  appropriate  list; 
note  that  this  entry  is  returned  (in  j)  as  the  value  of  function  xtnd.  del  is  a bit  more 
interesting.  It  searches  the  appropriate  list  for  the  entry  in  It  which  points  to  the  first  entry, 
j,  which  is  not  to  be  removed.  It  then  moves  the  entire  initial  portion  of  the  list  to  the  free 
space  list  by  simply  setting  the  proper  pointers.  If  all  the  entries  are  to  be  removed,  deleUl 
does  this;  it  calls  del  to  search  for  the  list-ending  zero  and  to  move  the  entire  list  to  the  free 
space  list,  fall  just  tests  if  the  free  space  list  is  empty. 
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The  predicate  suec  defined  in  the  concrete  invariant  is  closely  related  to  the  abstract 
predicate  follows.  Although  the  parameterizations  of  the  two  predicates  are  different,  they 
ask  the  "same'*  question  and  are  related  by 


follows<rep(sq,lt,free),  i,  j)  - succ(i,  j) 


The  form  indis(s,i)  defines  a generator  for  elements  of  the  integer  sequence  Sj,  starting 
with  first(sj).  Abstractly,  an  indis  is  composed  of  three  (sub)sequences,  the  first  containing  the 
elements  already  generated,  the  second  the  (singleton)  current  element,  and  the  third  the 
other  elements  yet  to  be  seen. 

In  [Shaw76b]  we  discussed  the  proof  rules  for  iteration  statements.  We  showed  that 
certain  simplifying  assumptions  about  the  generator  can  yield  simple  proof  rules;  these 
assumptions  are  satisfied  by  indis,  as  we  will  show  in  the  verification  of  condis.  We  therefore 
have  a proof  rule  for  the  for  statement  which  corresponds  closely  to  Hoare’s  sequence  rule 
and  also  a proof  rule  for  the  first  statement.  These  proof  rules  are  given  in  the  specifications 
of  indis,  and  indeed  constitute  the  major  part  of  those  specifications.  The  basis  for  this 
specification  technique  for  generators  is  given  in  [Shaw76b]. 


Verification  of  Condis 


We  can  now  verify  the  form  condis. 


For  the  form 

1.  Representation  validity 

Show;  I^(sq,lt,free)  a Ij,(rep(sq,lt,free)) 

Proof:  Iseji^sn  holds  by  the  bounds  on  sq[j]  and  lt[K]  and  the  fact  that  the 
r^  function  drops  the  zeroes  that  indicate  the  end  of  a list.  The  eji^’s 
are  distinct  because  the  multiset  {sq[j],  lt[k]}  contains  each  of  1,  2,  .... 
n at  most  once.  The  multiset  property  of  Ig  implies  $ucc(free,0)  and 
succ(sq[j],0). 

2.  Initialization 

Show:  nil  A mil  { mit  } Vi  < [0..m-l]  sqj-o  a I^ 

Proof;  After  init  we  have  free-1,  lt[l>2,  ...,  It[n-l]«n,  lt[n]-0,  sq[0]-0,  ..., 
sq[m-l]«0.  Using  the  function,  each  sqj-<>  since  each  sq[i]>0. 
nil  means  OsfreeSn.  The  bounds  on  sq[j]  and  lt[k]  and  the  multiset 
property  are  clear.  Vi  < [l..n](succ(free,i)  a •'succ(0,i». 
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For  i/m  function  atm/ 

3 Concrete  operation 

Shoifc  ■ freo^O  a i ( [0..m-l]  a { body  ) a 

Proof  The  tour  terms  of  are  dear  as  are  the  bounds  in  The 

muttiset  property  holds  because  the  body  permutes  the  values  s.free’, 
s sq‘(il  and  s It’fs  free’].  Since  the  head  of  s.free  moves  to  the  head  of 
ssqfi],  each  i ( [l..n]  still  satisfies  exactly  one  succ  term.  (and  1^) 
ensures  that  the  accesses  to  s.lt  and  s.sq  are  within  bounds. 

4a  holds 

Show:  A o 

Proof;  I ( I0..m-l]  is  immediate.  If  s.free-0,  then  the  multiset  property  of 
means,  using  the  r^  function,  that  the  SIGMA  term  is  exactly  n,  a 
contradiction.  Hence  s.free»<0. 

f^post 

Show:  A A 3 sqj-<j>-vsqj’ 

Proof:  Since  s.sqfi]-]  and  s.ltfj]*«s.sq’ri],  the  refi  function  gives  sqj»<j>'vsqj’. 

For  the  function  del 

3.  Concrete  operation 

Show;  /?j^  A { body  } s.sq[i]»j  a 1^ 

Proof:  If  s.sq[ij=j  then  holds  and  1^.  is  unchanged.  If  s.sq[i]jfj  then 
define  the  set  Gp  = { x | succ(s.sq[i],x)  A succ(x,p)}.  Add  the  ghost 
operation  "H«-H  u {k}"  after  "k»-s.lt[k]"  in  the  while  loop  and  add 
"H«-{k}"  after  "k<-s.sq[i]".  A while-loop  invariant  (placed  before  the 
test)  is  then  H«G^  because  Gssq[i]  “ 

H=G^  A s.lt[k])<j  3 H u (s.lt[k]}  = Gg  |f 

The  while  terminates  because  succ(s.sq[i],j)  and  s.sq[i]|fj.  At 
termination  s.lt[k]«j  and  H»G|^.  The  multiset  property  of  I^  holds 
because  the  last  three  statements  in  the  body  permute  the  values 
s.free’,  s.sq’[i],  and  s.lt’[k].  Furthermore,  each  element  in  H is  now  a 
successor  of  s.free  rather  than  of  s.sq[i].  All  other  successors  of 
s.sqp]  and  all  previous  successors  of  s.free  remain  so,  respectively. 
/Tpyf  and  the  bounds  in  1^,  are  clear. 

4a.  holds 

Show;  I^  A /?p^g  3 

Proof;  Immediate  from  /tp^e  Ig  condis. 

f^post 

Show;  I^  A /^prg  A 3 sqj-< 

Proof:  Only  sqj  changes,  sqj  now  begins  with  j and  there  are  no  other 
changes  to  sqj. 
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For  the  function  detail 

3.  Concrete  operation 

Show;  A Ij,  { s.del(s,i,0)  } s.sq[i]«^  A 1^. 

Proof:  and  the  multiset  property  of  1^  imply  in  holds  for  s.del.  (1^ 

holds  for  s.del  as  required.)  The  out  for  s.del  gives  s.sqfil-O. 
after  s.del  gives  after  delall. 

4a.  holds 

Show:  i ( [0..m-l]  s i c [0..m-l] 

Proof:  Immediate 

^post 

Show;  Ij.  A i < [0..m-l]  a s.sq[i]=0  o sqj=<> 

Proof:  Only  sqj  changes.  s.sq[i]-0  means  sqj-<>. 

For  the  function  full 

3.  Concrete  operation 

Show:  Ij.  { t<-s.free=0  } t = (s.free=0)  A 1^, 

Proof:  Immediate 
4a.  holds 

is  true 
/4pQ5(  holds 
Show;  A 

Proof:  t “ (s.free=0)  = (SIGMA  . . . = n)  using  the  multiset  property  of  1^. 


To  verify  the  indis  generator,  we  must  first  reconstruct  the  ore  and  post  conditions 
from  the  specified  proof  rules: 

&init 

post  (&b  » s.sqj»«>)  A (&b  ^ x = first(s.sqj)  A c = <>) 

&next 

pre  mbr(s,i,x) 

post  (&b  ■ dV<>)  A (&b  o X «» first(d’)  a c » c’'^<x’>) 


Next,  we  must  show  that  indis  satisfies  the  standard  aggregate  assumptions', 

(a)  The  indis  abstraction  is  explicated  in  terms  of  sequences.  The  normal  empty 

sequence  (■‘^>),  concatenation  operator  (»'),  and  leading  element  selector 
(first)  are  available. 

(b)  The  complete  sequence  to  be  generated  is  s.sqj,  which  can  be  decomposed  as 

indicated  in  the  clause  of  indis. 
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1 


! 


(c)  The  specifications  of  Sinit  and  &next  have  the  required  form. 

Furthermore,  indis  satisfies  the  ixutc  generator  assumptions  because  (a)  &init  and  Snext 
terminate  and  (b)  &init  and  Anext  alter  only  the  indis  variable  x (and  the  return  value  &b). 

Since  "sq",  "it",  and  "free"  are  unchanged  by  indis,  the  1^  of  condis  still  holds  and  will  be 
used  in  the  proof. 

r or  the  form  (indis) 

1.  Representation  validity 

Show:  o Ig,  i.e.,  true  o true 

Proof:  Immediate 

2.  Initialization 

Show:  0<i<m-l  { } true  a true 
Proof:  Immediate 

F or  the  function  &init 

3.  Concrete  operation 

Show:  true  { x«-s.sq[i];  &b<-Xi^0  } x=s.sq[i]  a (&b  s s.sq[i]j<0) 

Proof:  Clear 
4a.  /?j^  holds 
is  true 

'^post 

Show:  x=s.sq[i]  a (&b  s s.sq[i]i<0)  o 

(&b  5 s.sqji^o)  A (&b  3 X “ first(s.sqj)  a c = <>) 

Proof:  From  the  rep  function  for  indis,  s.sq,-  = (if  s.sq[i]«0  then  <>  else 
some  non-empty  sequence).  Hence  &b  h s.sq[i]r<0  h s.sqj><<>.  For  the 
second  term  of  the  conclusion,  assume  &b.  Then  x=s.sq[i]f<0  and  the 
final  clause  of  rep  gives  s.sqj  = c'^x>~d.  Since  x=s.sq[i]»pj,  then  c * 

<>  whence  also  x - first(s.sqj). 

For  the  function  &next 

3.  Concrete  operation 
Similar  to  fl’init.3 
4a.  /4j^  holds 

Show:  mbr(s,i,x)  o succ(s.sq[i],x)  a x»<0 

Proof:  mbr(s,i,x)  means  x»<0  by  Ig  for  condis.  The  term  succ(s.sq[i],x) 
follows  from  mbr(s,i,x),  the  re£  function,  and  the  definition  of  succ. 

4b.  /4post  holds 

Show:  mbr(s,i,x’)  a x«s.lt[x’]  A (&b  « s.ltlx’]j<0)  ^ 

(&b  ■ dV<>)  A (&b  3 X - first(d’)  a c - c’~<x’>) 


I 

li 

y 
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Proof:  mbr(s,i,x’)  means  xVO  and  s.sqj^o,  and  therefore  by  the  rep 
function  also  s,sq[i]?<0.  Hence  in  the  final  clause  of  the  rep  function, 

&b  a s.lt[x’]:<0  a dV<>.  For  the  second  term  of  the  conclusion,  assume 
&b.  Then  x=s.lt[x’]t^0  and  the  final  clause  of  rep  gives  s.sqj»c'v<x>'>'d 
and,  because  xVO,  also  s,sqj=c’~<x’>~<d’>.  Since  x<=s.lt[x’],  it  follows 
that  X - first  (d’)  and  c «*  c’~<x’>, 

QEO 


Examples  of  the  Use  of  Symtab 

In  this  section  we  shall  present  a skeletal  example  which  involves  three  different  styles 
of  usage  of  the  symtab  abstraction.  It  is  not  our  intent  either  to  make  this  example  complete 
or  to  suggest  that  the  utility  of  the  abstraction  is  limited  to  these  three  cases.  Rather,  we  j 

wish  to  bolster  the  reader’s  intuition  about  ways  in  which  the  abstraction  might  be  used.  I 

The  example  we  have  chosen  is  a multi-pass  compiler  for  an  Algol-like  (i.e.,  block- 
structured)  language,  and  indeed  we  have  restricted  ourselves  to  the  first  two  passes  -- 
lexical  and  syntactic  analysis,  respectively.  In  this  scheme,  the  first  pass  is  responsible  for 
reading  units  of  the  source  file  (identifiers,  literals,  punctuation  marks,  etc.)  and  converting 
them  to  an  internal  form  called  a "lexeme".  These  lexemes  are  written  onto  a file  which  will 
be  read  again  by  the  second  pass.  The  second  pass  is  responsible  for  reading  the  file  of  i 

lexemes  generated  by  the  first  pass  and  performing  syntactic  analysis.  Although  it  is  not 
important  to  our  example,  the  output  of  the  second  pass  will  likely  be  some  other  intermediate  t; 

representation  (e.g.,  reverse  polish  or  trees)  which  is  suitable  for  optimization  and  code  | 

generation. 

Here,  then,  is  the  skeletal  program;  more  detailed  comments  on  the  uses  of  the  symtab 
abstraction,  and  on  the  program  in  general,  follow  the  example. 

function  compiler  (source:  file(char))»  it 

beain  i| 

form  condis  . . .;  | 

form  symtab  . . 

form  id  extends  string=  ;; 

beginform  j: 

specifications  ; : 

function  hash  (s:id,  m:in1eger)  returns  k:integer  pre  m>0  post  Osk<m’j  hi 


endform: 
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form  lex  extends  integer- 
beginform 
specifications 

function  hash  (x:lex,  mrinteger)  returns  k:integer  pre  m>0  post  0<k<m’j 
endform: 
local  L:  file(lex); 
begin  ! pass  1 

local  NT;  symtab  (id,  127,  1000)i 

I 

! pure  lexical  pass,  see  discussion  below. 

I 

end; 

begin  ! pass  2 

form  attributes  = . . . ! see  discussion  below 

local  A:  vector  (attributes,  1,  2000); 
local  ST:  symtab  (lex,  127,  2000); 

I 

! syntactic  (parse)  analysis  pass;  see  discussion  below. 


end; 


This  program  first  defines  four  forms.  Symtab  and  condis  have  been  defined  in  detail 
previously  and  hence  are  not  repeated.  The  forms  id  and  lez  are  extensions  of  strings  and 
integers,  respectively,  and  merely  add  hashing  functions;  we  have  not  defined  the 
implementations  of  these  functions,  since  they  are  not  germane  to  the  example.  Note  too  that 
a file  of  lexes  is  defined  at  the  outermost  block  level;  this  file  is  the  explicit  interface  between 
the  first  and  second  passes. 

As  noted  earlier,  the  function  of  the  first  pass  is  to  convert  the  external  representation 
of  the  program  (a  file  of  characters)  into  a more  convenient  internal  form  --  namely  a file  of 
lexemes  (where  each  lexeme  represents  an  atom  of  the  language).  Since  this  pass  does  no 
syntactic  analysis,  in  particular  it  does  not  recognize  block  structure.  This  implies  that  all  ■ 

occurrences  of  the  same  atom  (e.g.,  "xyz")  will  be  mapped  to  the  same  lexeme.  This  mapping 
is  accomplished  through  the  use  of  the  NT  (for  name-table)  instantiation  of  symtab;  indeed,  the  j 

only  use  of  NT  is  to  obtain  this  unique  mapping  and  the  instantiation  is  therefore  deleted  on  j 

exit  from  the  block  in  which  the  first  pass  is  accomplished. 


\ 


ALPHARO;  A Symbol  Table  Example 


Page  25 


In  skeletal  form,  the  body  of  the  block  for  pass  1 might  look  somewhat  as  follows; 

open(source)j  open(L)t 
while  -«nd  of  file(source)  do 
begin 

local  i:id,  x:lex; 

I 

! do  whatever  is  appropriate  to  assemble  the  next  atom 
! from  the  source  file  into  "i". 

I 

[f  (x<-lookup(NT,i))>=0  a -ifulKNT)  then  x<-insert(NT,i); 
write  (L,x); 
end: 

rewind(L): 


Note  that  the  operations  enterbLock  and  leat/ebLock  are  not  used,  all  insert  operations 
are  done  at  the  same  block  level,  and  only  one  entry  per  atom  will  be  made. 

The  second  pass  is  substantially  more  complex  since  it  performs  the  full  syntactic 
analysis;  hence  we  will  not  even  attempt  to  illustrate  its  skeletal  form.  We  would,  however, 
like  to  point  out  several  things  about  it. 

First,  notice  that  this  block  defines  a form  named  attributes.  We  have  not  shown  the 
body  of  this  form,  since  it  will  be  highly  language-  and  machine-specific.  However,  the  notion 
is  that  this  form  provides  for  the  storage  and  manipulation  of  whatever  information  must  be 
retained  about  a symbol,  e.g.,  its  type,  run-time  storage  address,  array  bounds,  and  so  forth. 

Second,  we  have  declared  a vector.  A,  of  these  attribute  objects.  As  suggested  in  an 
earlier  section,  instances  declared  at  a given  block  level  will  be  associated  with  a unique 
integer,  but  this  integer  will  be  different  from  the  one  associated  with  the  same  identifier 
declared  at  a different  block  level.  These  integers  will,  in  turn,  be  used  as  indices  into  the 
vector  A (e.g.,  to  set  and  retrieve  information  about  the  identifier). 

Finally,  we  have  declared  another  instantiation  of  symtab,  ST.  This  one  will  be  used  to 
recognize  block  structure,  and,  specifically,  will  map  from  the  simple  lexemes  generated  in  the 
first  pass  into  indices  info  the  vector.  A,  of  attributes.  As  the  parser  detects  blocks  (begin- 
end  pairs)  in  the  source  program,  if  will  invoke  enterbLock  and  leavebLock.  The  declaration 
processing  routines  will  invoke  defined  to  determine  whether  an  identifier  has  been  declared 
twice  at  the  same  block  level  (presumably  an  error),  and  perform  insert  operations  to  define 
the  instances  of  the  identifier  at  the  current  block  level.  The  rest  of  the  compiler  will  perform 
lookup  operations  to  obtain  the  index  of  the  attribute  vector  entry  associated  with  specific 
lexemes.  (Note,  by  the  way,  that  by  appropriate  ordering  of  insert  and  lookup  operations  the 
declaration  processor  can  obtain  either  of  the  interpretations  of  "block-structure"  discussed  in 
the  introduction.) 
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Examples  of  the  Use  of  Symtab 


Before  leaving  this  example,  let  us  return  to  the  form  attributes  (defined  in  pass  2)  to 
illustrate  another  potential  use  of  the  symtab  abstraction.  As  was  mentioned  in  the 
introduction,  in  general  the  mapping  from  identifier  to  unique  integer  may  be  context- 
sensitive.  Block  structure  is  the  most  familiar  form  of  such  sensitivity,  but  another  is  name 
qualification,  as  in  field  selectors  for  records.  In  many  languages  one  makes  a declaration  such 
as 


x:record(name:string,  age:integer,  ziinteger); 

and  then  refers  to  "x.name",  "x.age",  and  "x.z".  A problem  arises  when,  at  the  same  block 
level,  there  is  another  declaration  such  as 

y:record{ss:integer,  ziboolean); 

In  such  a case  the  identifier  "z"  is  no  longer  unique  --  its  interpretation  depends  upon  the 
name  it  qualifies. 

There  are  many  ways  one  might  treat  this,  including  inserting  each  of  ”x",  "x.name", 
"x.age",  "x.z",  "y",  "y.ss",  and  "y.z"  as  complete  identifiers  in  ST.  An  attractive  alternative, 
however,  is  to  include  instantiations  of  symtab  in  each  of  the  attributes;  that  is,  to  make  form 
attributes  appear  somewhat  as  follows: 

form  attributes” 
beginform 

representation 

unique  qual:symtab(lex,l,10), 

endform; 


If  this  is  done,  then  to  determine  the  interpretation  of  "x.z"  one  would  first  search  ST 
for  the  index,  i,  associated  with  the  lexeme  for  "x",  then  search  A[i].qual  for  the  index 
associated  with  the  lexeme  for  "z". 

Although  this  compiler  example  has  been  sketchy,  we  hope  that  it  has  suggested  some 
of  the  ways  in  which  the  symtab  abstraction  may  be  applied.  The  details  of  the  example  are 
not  important,  except  insofar  as  they  help  the  reader’s  intuition;  what  ts  important  is  the 
notion  that  well-chosen  abstractions  have  many  uses.  The  class  of  broadly  useful  abstractions 
is  simply  too  large  to  include  them  all  in  a single  programming  language  --  hence  Alphard  has 
chosen  to  provide  a linguistic  facility  so  that  the  programmer  may  define  them.  Many  such 
(verified)  abstractions  will  find  their  way  into  the  library,  and  hence  incrementally  enhance  the 
"power"  available  to  the  programmer  — without,  at  the  same  time,  limiting  him  to  the  language 
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designer's  preconceived  notions  of  what  constitutes  an  appropriate  set  of  abstractions  (or,  for 
that  matter,  implementations). 


Conclusions 


A programming  language  is  a tool  for  the  construction  and  communication  of  programs; 
a&  such  its  utility  should  be  measured  relative  to  these  tasks.  In  other  words,  the  language 
should  be  as^d,  and  the  quality  of  that  use  must  be  judged.  While  this  is  true  of  any 
programming  language,  it  is  especially  so  of  one  such  as  Alphard,  which  departs  substantially 
from  those  in  common  use. 

Thus,  in  this  and  other  reports  we  are  attempting  to  exhibit  Alphard  in  relatively 
realistic  contexts  and,  along  with  the  reader,  to  judge  the  practical  utility  of  our  creation.  It  is 
far  too  soon  to  draw  definitive  conclusions  — that  must  await  the  use  of  Alphard  in  real 
programs  — but  we  would  like  to  share  some  of  our  impressions  resulting  from  these 
experiences. 

First,  the  symtab  abstraction  is  about  the  (conceptual)  size  we  envision  for  most 
abstractions;  larger  programs  will  be  constructed  by  further  "layering".  Thus  we  take  our 
ability  to  specify  and  verify  this  form  as  fairly  strong  evidence  that  larger  programs  will  also 
be  tractable. 

Second,  in  most  respects  the  implementation  is  a practical,  efficient  one.  This  reinforces 
our  intuitions  that  no  efficiency  need  be  sacrificed  to  obtain  clear,  verifiable  programs.  (The 
one  exception  to  this  statement  is  our  use  of  fixed-sized  vectors  and,  correspondingly, 
integers  for  the  unique  identification  of  symbols.  A more  realistic  implementation  would, 
perhaps,  have  done  true  dynamic  storage  allocation  and  used  references.  We  avoided  this 
implementation  primarily  because  it  would  have  carried  us  into  portions  of  Alphard  not 
covered  in  previous  reports,  but  also  because  those  portions  of  the  language  are  still  in  flux. 
We  trust  that  the  reader  will  forgive  this  departure  from  realism.) 

Third,  one  of  the  anticipated  advantages  of  an  Alphard-like  language  is  that  a library  of 
verified  abstractions  will  develop.  Both  of  the  forms  developed  here  might  well  go  into  that 
library  so  we  are  getting  some  evidence  that  this  hoped-for  advantage  will  be  realized. 

Fourth,  one  of  our  private  objectives  was  to  make  the  form  mechanism  strong  enough  to 
support  an  extremely  broad  class  of  abstractions  --  the  ultimate  target  being  the  spectrum 
covered  by  our  intuitive  notion  of  the  word  "abstraction".  The  evidence  is  not  conclusive,  but 
we  are  feeling  better  about  meeting  that  goal  all  the  time. 


Finally,  we  should  say  a few  words  about  our  experience  concerning  the  effort  needed 
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Conclusions 


to  define  a form.  It  should  be  clear  that  the  actual  code  in  a form  body,  i.e.,  the 
implementation  part,  is  roughly  the  same  size  as  the  corresponding  code  in  other  languages 
(although  the  first  statement  does  seem  to  shorten  many  of  the  examples).  Moreover,  for 
some  reason,  the  information  needed  for  verification  (abstract  and  concrete  invariants. 
abstract  pre  and  post  conditions,  function,  etc.)  usually  seems  about  equal  to  the  code 
size;  thus  a full  form  is  about  twice  the  size  of  the  code  alone.  This  does  not  particularly 
concern  us,  since  these  kinds  of  specifications  tend  to  replace  much  of  the  documentation  that 
would  otherwise  be  needed  — and  they  are  certainly  more  precise. 

We  find  the  verification  of  a form,  once  the  specifications  and  code  have  been  written, 
to  be  more  difficult  and  time-consuming  than  coding,  but  not  unreasonably  so  (say  by  as  much 
as  a factor  of  two  or  three).  Sometimes  it  is  necessary  to  modify  the  specifications,  or  the 
code,  during  the  verification  in  order  to  remove  inconsistencies  that  are  uncovered.  The 
verification  may  also  suggest  different  specifications,  usually  ones  that  are  more  constrained 
but  sometimes  simpler  ones.  In  spite  of  the  difficulties,  the  bodies  of  functions  tend  to  be 
small  and  their  proofs  correspondingly  small,  as  can  be  seen  from  these  examples.  Moreover, 
the  proofs  of  the  two  forms  syrntab  and  condis  were  independent.  To  date  our  proofs  have 
been  manually  generated,  but  we  envision  having  automated,  interactive  aids  in  the  future. 
These  should  reduce  the  verification  time  to  approximately  the  coding  time.  Since  this  is  less 
than  the  time  currently  spent  on  debugging,  we  feel  highly  encouraged. 

The  majority  of  our  time  goes  into  designing  and  specifying  the  abstraction.  There  are 
two  related  aspects  of  this:  getting  the  intuitive  abstraction  "right”,  and  formalizing  it  (at  least 
sufficiently  for  it  to  be  verified).  The  two  appear  related  in  that  difficulty  in  formalizing  an 
intuitive  abstraction  often  seems  to  uncover  muddy  thinking  at  the  intuitive  level.  While  we 
seem  to  be  improving  our  ability  to  formalize,  indicating  that  it  is  a learnable  skill,  we  have  no 
easy  rules  for  picking  the  right  abstraction  in  the  first  place.  While,  with  practice,  our  abilities 
in  choosing  abstractions  may  also  improve,  we  suspect  that  this  is  a fundamental  problem  of 
design  and  has  a significant  aesthetic  component. 

It  is  clear  that  we  are  just  learning  to  use  the  power  of  the  tools  we  are  creating  and 
exploring.  Much  remains  to  be  discovered  about  what  is  possible  or  impossible,  easy  or  hard, 
and  reasonable  or  unreasonable  to  do  with  the  facilities.  In  this  connection  we  note  that  an 
early  version  of  syrntab  was  a one-level  form,  used  no  generator  such  as  indis,  and  had  only 
some  of  the  same  verification  information.  Although  that  version  of  syrntab  used  the  same 
implementation  ideas,  it  was  essentially  incomprehensible.  When  we  realized  that  multiple 
ideas  were  becoming  confused,  we  separated  the  maintenance  of  the  lists  from  the  lookup 
algorithms.  The  result  was  that  the  code,  the  specifications,  and  the  verification  all  became 
much  more  manageable. 
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Appendix  A 

InfornDal  Description  of  Verification  Methodology 


Alphard’s  verificaHon  methodology  is  designed  to  determine  whether  a form  will  actually 
behave  as  promised  by  its  abstract  specifications.  The  methodology  depends  on  explicitly 
separating  the  description  of  how  an  object  behaves  from  the  code  that  manipulates  the 
representation  in  order  to  achieve  that  behavior.  It  is  derived  from  Hoare’s  technique  for 
showing  correctness  of  data  representations[Hoare72]. 

The  abstract  object  and  its  behavior  are  described  in  terms  of  some  mathematical 
entities  natural  to  the  problem  domain.  Graphs  are  used  in  [Shaw76a]  to  describe  binary 
trees;  sequences  are  used  in  [Wulf76a,b]  to  describe  queues  and  stacks  and  in  condis  to 
describe  list  processing,  and  so  on.  We  appeal  to  these  abstract  types 

- in  the  invariant,  which  explains  that  an  instantiation  of  the  form  may  be  viewed 

as  an  object  of  the  abstract  type  that  meets  certain  restrictions, 

- in  the  initiaHy  clause,  where  a particular  abstract  object  is  displayed,  and 

- in  the  pro  and  post  conditions  for  each  function,  which  describe  the  effect  the 

function  has  on  an  abstract  object  which  satisfies  the  invariant. 


The  form  contains  a parallel  set  of  descriptions  of  the  concrete  object  and  how  it 
behaves.  In  many  cases  this  makes  the  effect  of  a function  much  easier  to  specify  and  verify 
than  would  the  abstract  description  alone. 

Now,  although  it  is  useful  to  distinguish  between  the  behavior  we  want  and  the  data 
structures  we  operate  on,  we  also  need  to  show  a relationship  that  holds  between  the  two. 
This  is  achieved  with  the  representation  function  rep(x).  which  gives  a mapping  from  the 
concrete  representation  to  the  abstract  description.  The  purpose  of  a form  verification  is  to 
ensure  that  the  two  invariants  and  the  rep(x)  relation  between  them  are  preserved. 

In  order  to  verify  a form  we  must  therefore  prove  four  things.  Two  relate  to  the 
representation  itself  and  two  must  be  shown  for  each  function.  Informally,  the  four  required 
steps  are®: 


6 

We  will  use  Ig(rep(x»  to  denote  the  abstract  invariant  of  an  object  whose  concrete 
representation  is  x,  I^(x)  to  denote  the  corresponding  concrete  Invariant,  italics  to  refer  to 
code  segments,  and  the  names  of  specification  clauses  and  assertions  to  refer  to  those 
formulas.  In  step  4b,  "pre(rep(x’)>"  refers  to  the  value  of  x before  execution  of  the  function. 
A complete  development  of  the  form  verification  methodology  appears  in  [Wulf76a,b]. 
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For  the  form 

1.  Representation  validity 

l^.(x>  3 Ig(rep(x» 

2.  Initialization 

requires  { init  clause  } initiallvtreptx))  a I^.(x) 

For  each  function 

3.  Concrete  operation 

in(x)  A l^(x)  { function  body  ) outtx)  a 1^(x) 

4.  Relation  between  abstract  and  concrete 

4a.  I^(x)  A pre(rep(x»  o in(x) 

4b.  I^(x)  A pre(rep(x’))  a put(x)  3 post(rep(x)) 

Step  1 shows  that  any  legal  state  of  the  concrete  representation  has  a corresponding  abstract 
object  (the  converse  is  deducible  from  the  other  steps).  Step  2 shows  that  the  initial  state 
created  by  the  representation  section  is  legal.  Step  3 is  the  standard  verification  formula  for 
the  concrete  operation  as  a simple  program;  note  that  it  enforces  the  preservation  of  I^.  Step 
4 guarantees  (a)  that  the  concrete  operation  is  applicable  whenever  the  abstract  pre  condition 
holds  and  (b)  that  if  the  operation  is  performed,  the  result  corresponds  properly  to  the 
abstract  specifications. 


